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Abstract. The problem of testing a linear temporal logic (LTL) formula 
on a finite execution trace of events, generated by an executing program, 
occurs naturally in runtime analysis of software. An algorithm which 
takes a past time LTL formula and generates an efficient dynamic pro- 
gramming algorithm is presented. The generated algorithm tests whether 
the formula is satisfied by a finite trace of events given as input and runs 
in linear time, its constant depending on the size of the LTL formula. 
The memory needed is constant, also depending on the size of the for- 
mula. Further optimizations of the algorithm are suggested. Past time 
operators suitable for writing succinct specifications are introduced and 
shown definitionally equivalent to the standard operators. This work is 
part of the Path Explorer project, the objective of which it is to construct 
a flexible framework for monitoring and analyzing program executions. 


1 Introduction 

The work presented in this paper is part of a project at NASA Ames Research 
Center, called PathExplorer [10,9,5,8,19], that aims at developing a practical 
testing environment for NASA software developers. The basic idea of the project 
is to extract an execution trace of an executing program and then analyze it to 
detect errors. The errors we are considering at this stage are multi- threading er- 
rors such as deadlocks and data races, and non-conformance with linear temporal 
logic specifications. Only the latter issue is addressed in this paper. 

Linear Temporal Logic (LTL) [18, 16] is a logic for specifying properties of re- 
active and concurrent systems. The models of LTL are infinite execution traces, 
reflecting the behavior of such systems as ideally always being ready to respond 
to requests, operating systems being a typical example. LTL has been mainly 
used to specify properties of concurrent and interactive down-scaled models of 
real systems, so that fully formal correctness proofs could subsequently be car- 
ried out, for example using theorem provers or model checkers (see for example 
[11,6]). However, such formal proof techniques axe usually not scalable to real 
sized systems without a substantial effort to abstract the system more or less 
manually to a model which can be analyzed. Model checking of programs has 



2 The PathExplorer Architecture 


PathExplorer, PAX, is a flexible environment for monitoring and analyzing pro- 
gram executions. A program (or a set of programs) to be monitored, is supposed 
to be instrumented to emit execution events to an observer, which then examines 
the events and checks that they satisfy certain user-given constraints. The con- 
straints can be of different kinds and defined in different languages. Each kind of 
constraint is represented by a rule. Such a rule in principle implements a partic- 
ular logic or program analysis algorithm. Currently there are rules for checking 
deadlock potentials, datarace potentials, and for checking temporal logic formu- 
lae in different logics. Amongst the latter, several rules have been implemented 
for checking future time temporal logic, and the work presented in this paper is 
the basis for a rule for checking past time logic formulae. In general, the user 
can program new rules and in this way extend PAX in an easy way. 

The system is defined in a component-based way, based on a dataflow view, 
where components are put together using a “pipeline 7 ’ operator. The dataflow 
between any two components is a stream of events in simple text format, without 
any apriori assumptions about the format of the events; the receiving component 
just ignores events it cannot recognize. This simplifies composition and allows 
for components to be written in different languages and in particular to define 
observers of arbitrary systems, programmed in a variety of programming lan- 
guages . This latter fact is important at NASA since several systems are written 
in a mixture of C, C++ and Java. 

The central component of the PAX system is a so-called dispatcher . The 
dispatcher receives events from the executing program or system and then re- 
transmits the event stream to each of the rules. Each rule is running in its own 
process with one input pipe, only dealing with events that are relevant to the 
rule. For this purpose each rule is equipped with an event parser. The dispatcher 
takes as input a configuration script, which specifies from where to read the pro- 
gram execution events, and then a list of commands - a command for each rule 
that starts the rule in a process. 

The program or system to be observed must be instrumented to emit exe- 
cution events to the dispatcher. We have currently implemented an automated 
instrumentation module for Java bytecode using the Java bytecode engineering 
tool JTrek [14]. Given information about what kind of events to be emitted, this 
module instruments the bytecode by inserting extra code for emitting events. 
Typically, for temporal logic monitoring, one specifies what variables to be ob- 
served and in particular what predicates over these variables. The code will then 
be instrumented to emit changes in these predicates, more specifically toggles 
in atomic propositions corresponding to these predicates. The instrumentation 
module together with PathExplorer is called Java PathExplorer (JPAX). 

3 Finite Trace Linear Temporal Logic 

We briefly remind the reader the basic notions of finite trace linear past time 
temporal logic, and also establish some conventions and introduce some opera- 



never true since the last time F x was observed to be true, including the state 
when F\ was true; the interval operator, like the “since” operator, has both 
a strong and a weak version. For example, if Start and Down are predicates 
on the state of a web server to be monitored, say for the last 24 hours, then 
[Start, Down)* is a property stating that the server was rebooted recently and 
since then it was not down, while [Start, Down) w says that the server w r as not 
unexpectedly down recently, meaning that it was either not down at all recently 
or it was rebooted and since then it was not down. 

What makes past time temporal logic such a good candidate for dynamic 
programming is its recursive nature: the satisfaction relation for a formula can 
be calculated along the execution trace looking only one step backwards: 

t |= oF iff t \= F or (n > 1 and t n ~i |= <*F), 

t |= G F iff t |= F and (n > 1 implies t n - i |= G F), 

t [= F\ S s F 2 iff £ |= F 2 or (n > 1 and t F\ and £ n -i ^ F\ S s F 2 ), 

t )= Fi S w F> iff t H F 2 or ( t (= Fi and (n > 1 implies t n - 1 (= Fi S s F 2 )), 
t |= [Fi, F 2 ) s iff t ^ F 2 and (t |= F\ or (n > 1 and t n - 1 (= [Fi, F 2 ) 5 )), 

t (= [Fi,F 2 )u,. iff t ^ F 2 and ( t |= Fi or (n > 1 implies t n - 1 |= [Fi,F 2 )uO)- 

We call the past time temporal logic presented above ptLTL. There is a ten- 
dency among logicians to minimize the number of operators in a given logic. For 
example, it is known that two operators are sufficient in propositional calculus, 
and two more (“next” and “until”) are needed for future time temporal logics. 
There are also various ways to minimize ptLTL. Let ptLTL\o P s be the restriction 
of ptLTL to propositional operators plus the operations in Ops. Then 

Proposition 1. The 12 logics 2 ptLTL\^s a }y ptLTL\^s v ,}? ptLTL [{ 0 ,[) a }? 
ptLTL r {e ,[)„ } , ptLTL ptLTL\ {1tS „}, ptLTL] { tiD . } , ptLTL [ {t , [M , and 

ptLTL\ {us ,}, ptLTL\ {ltSu ,}, ptLTL\ {U) , } , ptLTL\ Ut[)w} , are all equivalent. 

Proof. The equivalences follow 7 by the following easy to check properties: 

o F = true S s F 

□F = ~ ><s> -«F 

F x S w F 2 = (□ F x ) V (Fi S s F 2 ) 
bF = F Syr false 
oF = ->0^F 

Fi 5, F 2 = (*F 2 ) A (F x F 2 ) 
t F = F A - oF 
IF — -»F A ©F 

[Fi,F 2 ) s = _ 'l r 2 A ((o-iF 2 ) Ss Fl ) 

[F u F 2 ) w = -F 2 A ((°-F 2 ) <S w Fi) 

| F = t -F 
t F = 4. -.F 

[Fi, F 2 ) w = (G-iF 2 ) V [Fi, F 2 ) s 

[F t , F a ), =(»Fi) A[Fi,F a ) M 

0 F = (F — ¥ ~~ 1 'l F) A (~^F — >,[. F) 

F] S s F 2 =F 2 V[ gF 2 , ->Fi) 5 


2 The first two axe known in the literature [16]. 



problem. An important observation is, however, that, like in many other dynamic 
programming algorithms, one doesn’t have to store all the table s[l..n, 0..8], 
which would be quite large in practice; in this case, one needs only s[i,0..8] and 
s[i — 1,0. .8], w'hich we’ll write noiu[0..8] and pre[0..8] from now on, respectively. 
It is now only a relatively simple exercise to write up the following algorithm for 
checking the above formula on a finite trace: 

State state <— {}; 
bit pre[0..8]; 
bit nou/[0..8]; 

INPUT: trace t — eie 2 -.-e n ; 

/* Initialization of state and pre */ 

state 4— update(state : e i); 

pre[8] <- s (state)] 

pre[7 ] <r~ r (state)] 

pre[6] pre[ 7] or pre[8}] 

pre[5] <— false; 

pre[ 4] <r- q(state)] 

pre[ 3] pre[ 4] and not pre[b\] 

pre[ 2] p(state)] 

pre[ 1] <— false; 

pre[ 0] not pre{ 1] or pre[ 3]; 

/* Event interpretation loop */ 
for i = 2 to n do { 

state <— update(state,ei)] 
now[8] s (state)] 

now[ 7] <r- r (state); 
now\6\ noto[7] or notu[8]; 
notr[5] e- noiu[6] and pre[6]; 
now[ 4] f- g(state); 

nou;[3] (pre[3] or noio[4]) and not now[ 5]; 

nou;[2] p(state)] 

now\\] -f- nota[2] and no£ pre[2]; 

noiu[0] «— no£ notofl] or noio[3]; 

if nota[0: = 0 then output( f 'property violated J J ); 
pre r- now] 

}; 

In the following we explain the generated program. 

Declarations Initially a state is declared. This will be updated as the input 
event list is processed. Next, the two arrays pre and now are declared. The 
pre array will contain values of all subformulae in the previous state, w r hile 
now will contain the value of all subformulae in the current state. The trace 
of events is then input. Such an event list can be read from a file generated 
from a program execution, or alternatively the events can be input on-the-fly 
one by one when generated, without storing them in a file first. The latter 
solution is in fact the one implemented in PAX, where the observer runs in 
parallel with the executing program. 



Input: past time LTL formula p 

let po,Pi,-—,Pm be the subformulae of p \ 

output(“State state <— {};”); 

output (“bit pre[ 0 ..m];”); 

output(“bit now[0..m 

output (“Input: trace t = e 1 e 2 --e n f); 

output (“/* Initialization of state and pre */”); 

output ( il state 4— update(state. e i);”); 

for j — m downto 0 do { 

output ( “ pre[\ j , “] <- ”); 

if ^ is a variable then output^, “(state);”); 

if ipj is true then output(“true;”); 

if ifj is false then output(“false;”); 

if pj -i (pjt then output(“no£ prep’ 

if op cpj 2 then output ( “prep’ ji , “] op pre[” 

if pj = [^,^2)5 then output ( “prep’ ji, “] and not prep 5 , jf 2 , “];”); 

if ifj =t pj, then output ( “false;”); 

if ip- tpjt then output (“false;”); 


output(“/* Event interpretation loop */”); 
output (“for i = 2 to n do {”); 
for j — m downto 0 do { 

output(“ nott?p’ j j, “] «— ”); 

if <pj is a variable then output(<p ; , “(state);”); 

if pj is true then output(“true;”); 

if pj is false then output( “false;”); 

if ipj = -npj* then output (“not now[” j* , “];”); 

if <pj — ^ op (fj 2 then output (“noiop’ji, “] op notrp’, jo, 

if = [^,^3)5 then 

output (“(prep 5 , j , “] or noiop’ jj, “]) and not noiop’, j 2 , 

if =f then 

output ( “no top 5 , j', “] and not prep’, j', “];”); 
if =J, ipj, then 

output (“not notap 5 , j\ “] and prep 5 , j', “];”); 


}; 

output ( “ 
output(“ 
output( “} 55 ); 


if now[0] = 0 then output^ 'property violated 5 ’);”); 
pre <— nota; 55 ); 


where op is any propositional connective. Since we have already given a detailed 
explanation of the example in the previous section, we shall only give a very 
brief description of the algorithm. 

The formula should be first visited top down to assign increasing numbers to 
subformulae as they are visited. Let po, <Pi, -**5 Vm be the list of all subformulae. 
Because of the recursive nature of ptLTL , this step insures us that the truth value 
of t{ |= pj can be completely determined from the truth values of ti Pj> 
for all j < j f < m and the truth values of t {- 1 \= pj' for all j < j ' < m. 



class constructor takes as parameter a reference to the object that represents 
the state such that any updates to the states by the monitor based on received 
events can be seen by the evaluate () method. The generated Formulae class 
for the above specification looks as follows: 

class Formulae { 

abstract class Formula^ 

protected String name; protected State state; 
protected boolean[] pre ; protected boolean!] now; 

public Formula(String name, State state) { 
this. name = name; this. state = state; 

> 

public String getName(){return name;} 
public abstract boolean evaluate (); 

> 

private List formulae ~ new ArrayListO; 

public void evaluate (){ 

Iterator it * formulae . iterator 0 ; 
while (it .hasNextQH 

Formula formula — (Formula) it . next () ; 
if ( ! formula . evaluate () ) { 

System. out .println ("Property " + formula. getName () + " violated"); 

»> 

class Formula_P extends Formula^ 
public boolean evaluate (){ 
now[8] = state . holds ( M s M ) ; 
now [7] = state . holds ("r") ; 
now[6] = now[7] |j now[8] ; 
now [5] = ! now [6] fefc pre [6] ; 
now[4] = state holds ("q") ; 
now[3] * (pre [3] II now[4]) !now[5]; 

now[2] = state . holds ("p") ; 
now[l] * now [2] fcft !pre[2]; 
now[0] = !now[l] il now [3]; 

System . array copy (now ,0, pre ,0,9) ; 
return now[0] ; 

> 

public Forniula_P (State state)-{ 
super("P" , state) ; 

pre :s new boolean(9) ; now = new booleanl9] ; 

pre[8] = state .holds ("s") ; 

pre [7] = state . holds ("r") ; 

pre[6] = pre [7 ] II pre[8]; 

pre [5] = false ; 

pre[4] = state . holds ("q") ; 

pre [3] = pre [4] kk 'pre [5]; 

pre [2] = state . holds ("p ") ; 

pre [1] * false ; 

pre [0] = !pre[l] II pre [3]; 

> 

> 

public Formulae (State state){ 

formulae . add(new Formula_P (state) ) ; 

> 

> 

The class contains an inner abstract 3 class Formula and, in the general case, an 
inn er class Formula extending the Formula class for each formula in the spec- 
ification, where X is the formula’s name. In our case there is one such Formula_P 
class. The abstract Formula class declares the pre and now arrays, without giving 


3 An abstract class is a class where some methods are abstract, by having no body. 
Implementations for these methods will be provided in extending subclasses. 



A first observation is that not all the bits in pre are needed, but only those 
which are used at the next iteration, namely 2, 3, and 6 . Therefore, only a bit per 
temporal operator is needed, thereby reducing significantly the memory required 
by the generated algorithm. Then the body of the generated “for” loop becomes 
after (blind) substitution (we don’t consider the initialization code here): 

state <r~ update(state , e*) 
now[ 3] <r- r(state) or s(state) 

notv[ 2] f- (pre[2] or q( state)) and not (not now[3\ and pre[S]) 
now[ 1] p(state) 

if ((not (now[l\ and not pre[ 1]) or now[ 2]) = 0) 
then output(‘ ‘property violated' '); 

which can be further optimized by boolean simplifications: 

state update(state } 6j) 
now[3] e- r(state) or s(state) 

now[ 2] e- (pre[ 2] or q(state)) and (now[ 3] or not pre[ 3]) 
now[l] e- p(sia£e) 

if (notofl] and not pre[ 1] and not now[2]) 

then output(‘ ‘property violated' '); 

The most expensive part of the code above is clearly the function calls, namely 
p(state), q(state), r(state), and s(state). Depending upon the runtime require- 
ments, the execution time of these functions may vary significantly. However, 
since one of the major concerns of monitoring is to affect the normal execution 
of the monitored program as little as possible, especially in the inline monitor- 
ing approach, one would of course want to evaluate the atomic predicates on 
states only if really needed, or rather to evaluate only those that, probabilis- 
tically, add a minimum cost. Since we don’t want to count on an optimizing 
compiler, we prefer to store the boolean formula as some kind of binary deci- 
sion diagram, more precisely, as a term over the operation _?- : for example, 

pre[ 3] ? pre[ 2] ? now[ 3] : q(state) : pre[ 2] ? 1 : q(state) (see [9] for a formal 
definition). Therefore, one is faced with the following optimum problem: 

Given a boolean formula p using propositions ai, d2, ■■■, of costs Ci, c 2, 
c n , respectively, find a (_?_ : _)-expression that optimally implements ip. 

We have implemented a procedure in Maude [1], on top of a propositional cal- 
culus module, which generates all correct (_?_ : -) -expressions for 9 ?, admittedly 
a potentially exponential number in the number of distinct atomic propositions 
in tp 7 and then chooses the shortest in size, ignoring the costs. Applied on the 
code above, it yields: 

state update(state, ej) 
now[ 3] <r- r (state) ? 1 : s (state) 

now[ 2] pre[ 3] ? pre[ 2] ? now[ 3] : q(state) : pre[ 2] ? 1 : q(state) 

now[ 1] e-- p(state) 
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